VPC Ingress Routingとは何かを噛み砕いて理解してみる
コンバンハ、千葉（幸）です。
2019年12月に新発表となったVPC Ingress Routingですが、初見でなかなか理解に苦労しました。
ルートテーブルをインターネットゲートウェイおよび仮想プライベートゲートウェイと関連付けることができるようになりました。また、Amazon Virtual Private Cloud (Amazon VPC) の受信および送信トラフィックを VPC の仮想アプライアンスを通してリダイレクトできるようになりました。
発表時にはすでに弊社千葉（淳）が設定方法などをブログにしているのですが、パッと見ではなかなか理解が追いつかず。
少し遠回りして、噛み砕いて理解してみます。マネジメントコンソール上での操作は上記のブログが詳しいので、併せてお読みいただければと思います。
目次
- 目次
- 先に結論
- ルートテーブルの整理
- VPC内へのインターネット経由の通信を考えてみる
- アウトバウンドの方向
- ゲートウェイルートテーブルの制限
- ゲートウェイルートテーブルはマネジメントコンソール上でどう見えるか
- 終わりに
- 参考サイト
先に結論
- 特定のゲートウェイにルートテーブルを関連付けられるようになった
- インターネットゲートウェイ（IGW）と仮想プライベートゲートウェイ（VGW）である
- 上記の関連付けをエッジアソシエーションと呼ぶ
- エッジアソシエーションされたルートテーブルをゲートウェイルートテーブル と呼ぶ
- ゲートウェイルートテーブルには以下の制限がある
- 送信先として指定できるのはVPCのCIDRの範囲内のみ
- ターゲットに指定できるのは「local」か「ネットワークインタフェース」のみ
- 「ルート伝達」が有効であってはならない
- ゲートウェイルートテーブルによって、VPCへのインバウンドを細かくルーティングできるようになった
- 送信先IPとは異なるインタフェースにルーティングが可能に
- ルーティング先のサーバでIPフォワードされる設定がされていることが必要
- ルーティング先のEC2で「送信元/送信先チェック」は無効であることが必要
ルートテーブルの整理
ルートテーブルの概念についておさらいしましょう。
これまではVPC上のルートテーブルと言えばサブネットに関連付けるものでしたが、IGW、VGWに対しても関連付けることが可能となりました。
上記のゲートウェイに関連づける場合は、特にエッジアソシエーションと呼ばれます。
種類が増えてきて紛らわしくなってきたので、しっかり抑えておきましょう。
- サブネットルートテーブル
- サブネットに関連づけるルートテーブル
- ゲートウェイルートテーブル
- IGWないしVGWに関連づけるルートテーブル
- ローカルゲートウェイルートテーブル
- Outpostsを利用する際のローカルゲートウェイに関連づけるルートテーブル
- トランジットゲートウェイルートテーブル
- トランジットゲートウェイを利用する際の、（VPC側でなく）トランジットゲートウェイ側に関連づけるルートテーブル
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Route_Tables.html
今回はゲートウェイルートテーブルについての話です。
VPC内へのインターネット経由の通信を考えてみる
ゲートウェイルートテーブルの働きについて、今回はIGWを経由した場合の通信について考えてみます。
ユーザがパブリックサブネット上のEC２インスタンスに対してアクセスしたいとします。
従来の考え方
ユーザは、IP直指定であれ名前解決の結果であれ、EC2が持つパブリックIPに対してアクセスを行います。VPCに到達した時点で、宛先IPは「パブリックIPと紐付くプライベートIP」に変換されます。 （そういった変換は、インターネットゲートウェイに内包されるルータが持つNATテーブルに基づき行われているものと考えています。）
これまではゲートウェイルートテーブルという概念がなかったため、NATテーブルによる変換後のプライベートIPに対して、そのままアクセスがルーティングされます。 （言ってみれば、以下のルートのみを持つゲートウェイテーブルが暗黙的に設定されていたとも考えられます。）
| 送信先 | ターゲット |
|---|---|
| VPC全体のCIDR | local |
そこをインターセプトしてIDSなどのアプライアンス製品を経由させたい場合、これまでは様々な対応が必要でした。
アプライアンスを別VPCに構築し、TransitGatewayと組み合わせるパターン- できるだろうと思って書いてみましたが、どうしてもインターネット経由のインバウンドに対して実現する方法が思いつきませんでした‥
- アプライアンスとクライアントでトンネルを構築するパターン
- クライアントはアプライアンスのIPを指定して接続し、そこからNATするパターン
VPC Ingress Routing
VPC Ingress Routingによって、IGWを経由したインバウンドのルーティングに対してAWSカスタマーが干渉できるようになりました。ゲートウェイルートテーブルで定義することにより、本来の宛先でないアプライアンスサーバに対してトラフィックを向かせることが可能となります。
具体的には、以下のルールを定義することで実現できます。
| 送信先 | ターゲット |
|---|---|
| アプリケーションサーバが所属するサブネット | アプライアンスサーバにアタッチされているネットワークインタフェース |
アプライアンスサーバは、受け取ったトラフィックに指定されている宛先IPに対してIPフォワードを行います。宛先IPが自身でないトラフィックをブロックしないために、EC2ではデフォルトで有効になっている「送信先/送信元チェック」を外しておく必要があります。
IPフォワードの設定や、アプライアンスサーバからアプリケーションサーバへの通信は、特段新しい機能ではありません。あくまで、VPCに対して入ってくる通信をVPC内で細かくルーティングできるようになった、というのがVPC Ingress Routingです。
アウトバウンドの方向
アプリケーションサーバからユーザ側への通信を行う際にアプライアンスサーバを経由させたいとなった場合、それはアプリケーションサーバが所属するサブネットのルートテーブルによって制御される部分であり、それ自体は新しい機能ではありません。
サブネットテーブルに以下のようなルートを登録することで実現します。有名どころだと、NATインスタンスを使用する際に同じような指定の仕方をします。
| 送信先 | ターゲット |
|---|---|
| 0.0.0.0/0 | アプライアンスサーバにアタッチされているネットワークインタフェース |
ゲートウェイルートテーブルの制限
こちらを参照するのがわかりやすいかと思います。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Route_Tables.html#gateway-route-table
次のいずれかに該当する場合、ルートテーブルをゲートウェイに関連付けることはできません。
・ルートテーブルには、ネットワークインターフェイスまたはデフォルトのローカルルート以外のターゲットを持つ既存のルートが含まれています。
・ルートテーブルには、VPC の範囲外の CIDR ブロックへの既存のルートが含まれます。
・ルートテーブルに対してルート伝達が有効です。
あくまで、外部からやってくるVPC内へのトラフィックのルーティングにおいて、特定のネットワークインタフェースをターゲットとして指定することができるというものです。 条件を満たさないものをエッジアソシエーションしようとしたり、すでにエッジアソシエーション済みのものを条件を満たさない形に編集しようとすると、エラーになります。
ゲートウェイルートテーブルはマネジメントコンソール上でどう見えるか
従来のルートテーブル（サブネットルートテーブル）と同じ画面で管理・設定が可能です。
[アクション]ボタンに[Edit edge associations]という選択肢が増えているので、そこから設定が可能です。
設定後のルートテーブル一覧は以下のような表示になります。
Edge associations列に、エッジアソシエーション先のゲートウェイのIDが表示されているのがゲートウェイルートテーブルです。
設定上は、「サブネットルートテーブルかつゲートウェイルートテーブル」の作成も可能ですが、管理上のデメリットしか感じないため、それぞれ分けて作成する方が好ましいでしょう。
終わりに
ルートテーブルをインターネットゲートウェイおよび仮想プライベートゲートウェイと関連付けることができるようになりました。また、Amazon Virtual Private Cloud (Amazon VPC) の受信および送信トラフィックを VPC の仮想アプライアンスを通してリダイレクトできるようになりました。
改めて上記の文言を見ると、後半の文章は「間違ってないけどわかりづらい‥」という印象です。「VPCの仮想アプライアンスを通してリダイレクトさせる構成が容易に構築できるようになりました」あたりが言わんとしていることなのかなと思います。
理解の一助になれば幸いです。
![[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
